The difficult challenges of providing secure communications over the Internet are exacerbated in vehicle networks, such as the Vehicle Integration Infrastructure (VII). VII is a US Department of Transportation (DOT) intelligent highways initiative (National Highway Traffic Safety Administration (NHTSA), Vehicle Safety Communications Project Task 3 Final Report-Identify Intelligent Vehicle Safety Applications Enabled by DSRC, March 2005) that is a vehicle network aimed at improving highway safety and reducing congestion through the use of vehicles that can communicate with an intelligent infrastructure and vehicles that can communicate with each other.
There are two basic types of communications in VII: Vehicle-to-Infrastructure (V2I) and Vehicle-to-Vehicle (V2V). V2I communication is used for vehicles to communicate with roadside equipment (RSE) and back-end servers, while V2V communication is used for vehicles to directly commicate with each other. In Boneb D., Franklin M., Identity-Based Encryption from the Weil Pairing, Advances in Cryptology—Proceedings of CRYPTO 2001, Lecture Notes in Computer Science, Springer-Verlag, the authors describe V2I applications spanning safety, mobility, and infotainments services. Boneh and Franklin also describe V2V applications that are presently dominated by cooperative safety applications, such as emergency electronic brake lights, lane change warning, and cooperative forward collision warning. However, additional V2V consumer applications are likely to evolve.
Most V2I applications, such as probe data collection and toll payment, require secure communications to protect privacy and prevent eavesdropping, message forgery, masquerading, and other kinds of attacks. These applications typically do not need long communication sessions and therefore prefer to use a lightweight transport protocol, such as User Datagram Protocol (UDP), for data transport. In addition, V2I applications typically do not require a secure session to span multiple RSE zones. Instead, the secure sessions of V2I applications need only persist within a single zone. In a typical application, a vehicle entering an RSE zone requests and establishes a secure UDP session with an application running on the RSE or on a back-end server The vehicle conducts its communication and then disconnects prior to leaving the zone.
FIG. 1 shows a typical vehicle infrastructure 10, e.g. VII, as known in the art. The primary components of the VII as illustrated in FIG. 1 are On-Board Equipment (OBE) (not shown) located in each vehicle 12, a network infrastructure with access points called Roadside Equipment (RSE) 14; and a multitude of Applications 16, typically with a client that executes on the OBE and servers 18 associated with back-end applications located in the network infrastructure 10.
As shown in FIG. 1, wireless links among vehicles 12 and between vehicles 12 and RSEs 14 is inherently insecure because all parties within range of the radio signal can acquire it. Any communications sent across the air in clear text can be eavesdropped. Messages may be manipulated if not integrity-protected. Further, if not authenticated, any communicating party may be impersonated. Therefore, secure UDP sessions are needed between client applications running on the OBE and server applications 18 running on the RSE 14 or in the back-end VII infrastructure 10. Security mechanisms for such systems need to take into account a large number of mobile nodes, limited over-the-air bandwidth, and unreliable, intermittent network connectivity. In addition, the privacy of vehicles 12 and their operators needs to be preserved while still being able to authenticate them and remove intruders.
The Internet Engineering Task Force (IETE) Datagram Transport Layer Security (DTLS) secure session protocol is the UDP version of the popular Secure Sockets Layer (SSL)/Transport Layer Security (TLS), which is described in Fujisaki E., Okamoto T., Secure Integration of Asymmetric and Symmetric Encryption Schemes, Advances in Cryptology; Proceedings of CRYPTO 99, Lecture Notes in Computer Science, vol. 1666, Springer-Verla. DTLS mimics the TLS capabilities over UDP transport, providing a reliable handshake method for establishing secure sessions over best-effort datagram transport. Therefore, DTLS provides the basis for providing strong security to the UDP communications of on-vehicle applications in the VII network.
A secure session in DTLS is negotiated by an application client and an application server using the DTLS handshake procedure. The DTLS handshake procedure consists of three (3) rounds of message exchange. DTLS sessions are always initiated by a client by sending a ClientHello message to the server. The server verifies the message using HelloVerifyRequest. The first round of messaging is primarily used to thwart denial of service and amplification attacks. The second round of messaging is used for authentication and key exchange. In this round, the server sends a group of messages including ServerHelloCertificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone. At the end of the second round of handshake messaging, the server awaits a client response. The third round of messaging begins with the client sending its certificate in the Certificate message. The ClientKeyExchange message represents the final message that will be used by both client and server to compute a premaster secret. When all rounds have successfully transpired, the handshake is complete, making the session official, and data can be exchanged using the DTLS record protocol. Throughout the handshake exchange, any mis-ordering of messages, failures, or unexpected responses are handled by error and closure alerts.
However, DTLS lacks security requirements necessary in certain infrastructures, such as a vehicle infrastructure, e.g. VII. First, DTLS relies on digital certificates for entity authentication. Therefore, by definition, the identities of DTLS users are always known, and privacy cannot be preserved. Furthermore, when establishing a new session in DTLS, the communicating parties exchange arbitrarily long chains of certificates in order to successfully authenticate each other. Given that the size of a certificate can be large, e.g., typically a few thousand bytes for a certificate with a 1024-bit key pair, the over-the-air bandwidth requirement for exchange of certificate chains can be prohibitively large, especially in a radio zone with heavy traffic. In addition, use of digital certificates requires the ability to revoke certificates by way of certificate revocation lists (CRLs). Over-the-air distribution and/or update of CRLs would require a significant amount of network bandwidth in a Dedicated Short Range Communications (DSRC) zone.
Therefore, transport layer security as currently known in the art lacks certain features to secure UDP communications in the VII and similar infrastructures. First, such known security provides no support for privacy-preserving measures or 1609.2 vehicle certificates. Second, such known security requires multiple rounds of handshake messaging to establish a secure session. Some handshake messages, such as the ones used to exchange certificates, can be very long. In an unreliable wireless environment with relatively small RSE zones and vehicles traveling at highway speeds, the time needed to complete the handshake detracts from the limited available time to complete the transaction while the vehicle is still within the zone. Third, such known security requires the direct transmission of certificates during the handshake procedure for authentication. Certificates can be quite large and would unnecessarily consume limited air link bandwidth on the service channels.
The following abbreviations are used throughout:    AES Advanced Encryption Standard    CA Certificate Authority    CBC Cipher Block Chaining    CRL Certificate Revocation List    DSRC Dedicated Short Range Communications    DTLS Datagram Transport Layer Security    HMAC Keyed-Hash Message Authentication Code    IBE Identity-Based Encryption    IETF Internet Engineering Task Force    MAC Message Authentication Code    OBE On-Board Equipment    PKI Public Key Infrastructure    POC Proof of Concept    PST Provider Service Table    RSE Roadside Equipment    SSL Secure Socket Layer    SSS System Subsystem Specification    TLS Transport Layer Security    UDP User Datagram Protocol    V2I Vehicle-to-Infrastructure    V2V Vehicle-to-Vehicle    VDTLS Vehicle Datagram Transport Layer Security Protocol    VII Vehicle Infrastructure Integration    WAVE Wireless Access in Vehicular Environments    WSA WAVE Service Advertisement    WSMP WAVE Short Message Protocol